30 天真的走完啦！！！

第一天開始寫這個系列的時候，我一直會想到第一次做專案時，那個有點迷茫的自己。

明明已經學過 Database、API、Git，也寫過一些 Frontend 和 Backend，但真的站到一個完整專案前面時，它們還是像一顆一顆散落在腦袋裡的點。

每一顆好像都認得，卻不知道該怎麼把它們連成線。

不知道一個完整專案到底還有哪些地方要注意，也不知道自己現在站在哪裡、接下來又該往哪裡走。

所以開始寫這個系列時，我心裡一直想著：

如果第一次做專案時，我也有這樣一張地圖就好了。

也希望現在把它整理出來之後，可以幫到跟當時的我一樣，第一次站在完整專案前、還在找方向的小白們。

所以 Day1 的時候，我先把這趟工程世界的冒險分成三大關：

第一關｜規劃設計
        ↓
第二關｜核心開發
        ↓
第三關｜實際運行＆優化

真實開發本來就會來來回回，所以不是所有專案都一定按照這個順序走。

但可以先把它當作一張指引方向的 專案地圖。

先知道工程世界裡大概有哪些區塊、每一塊在處理什麼，原本散落的知識，也會比較容易一點一點接起來。

今天最後一天，就一起簡單回頭看看，這張地圖一路都裝進了哪些東西吧！

第一關｜規劃設計：還沒開始做，前面其實已經決定了很多事

回頭看看第一關，會發現我們那時候其實還沒有真的進入大量寫 Code。

但很多會一路影響後面的事情，已經在這裡慢慢定下來了。

產品要解決什麼問題？這一版又要先做到哪裡？

從技術、資料到使用者怎麼走，很多方向都會在真正大量寫 Code 以前慢慢定下來。

所以這一關，我們先把專案開始以前需要看清楚的幾個地方，一個一個攤開來：

第一關｜規劃設計
│
├─ 需求與產品規劃
├─ 技術選型
├─ 資料模型設計
├─ 資料庫規則與約束
├─ 介面設計
└─ AI 協作規範

• 需求與產品規劃
  先確認產品要解決什麼問題、有哪些功能，以及這一版做到哪裡。Function Map 幫我們看全貌，MVP 則幫忙在時間和資源有限時做取捨。

• 技術選型
  技術沒有單純的「最好」，真正要看的是它適不適合現在的需求、團隊、時間和成本。選一套技術，也代表一起接受它的 Trade-off。

• 資料模型設計
  Entity、Relationship、Cardinality 決定資料之間怎麼連，也會影響產品之後能不能自然長出新的功能。

• 資料庫規則與約束
  Constraint 可以把重要的資料規則直接留在 Database，像 NOT NULL、UNIQUE、CHECK、Foreign Key，都在幫我們守住資料的正確性。

• 介面設計
  User Flow、Wireframe、Prototype 幫我們先看清楚使用者怎麼走、功能怎麼接，也讓團隊對同一個產品有比較一致的想像。

• AI 協作規範
  AI 每次拿到的 Context 都有限，所以 CLAUDE.md、AGENTS.md 這類專案層級規範，可以把需要長期遵守的架構、規則和工作方式留下來。

這些事情當然不會第一天就全部定死。

但至少在真的開始往下做以前，我們已經先知道：有哪些地方值得先想清楚。

第二關｜核心開發：一個功能看起來很簡單，往裡走卻一層又一層

第二關開始之後，我們終於真的往 Code 裡走了。

但也是到了這裡才會發現：

一個功能要真的放進專案裡，原來不是「寫得出來、跑得動」就結束了。

專案要先跑得起來、Code 要有人一起改，功能本身還要有規格、有方法驗證；再往裡走，還會碰到登入、API、狀態流程，甚至多人同時操作資料時的問題。

所以這一關，我們一路拆開了：

第二關｜核心開發
│
├─ 開發環境與專案結構
├─ 版本控制與多人協作
├─ SDD 與 TDD
├─ 登入驗證與 Web Security
├─ API 設計與錯誤處理
├─ State Machine
└─ 並發控制

• 開發環境與專案結構
  Environment Setup 讓專案知道要在什麼條件下跑起來；Project Structure 則幫我們在 Code 越來越多之後，把不同責任整理清楚。

• 版本控制與多人協作
  Git、Branch、Pull Request、Review，加上 Git Flow 這類分支規則，都是在幫團隊一起管理同一份 Codebase。除了保存版本，也讓每一次修改都有脈絡、有人檢查，知道最後要怎麼合回共同版本。

• SDD 與 TDD
  SDD 先把「系統應該怎麼運作」說清楚；TDD 再用 Test 把「怎樣才算正確」留下來，讓需求和正確行為不只存在一段 Prompt 或某個人的腦袋裡。

• 登入驗證與 Web Security
  一顆登入按鈕背後，其實還有 Authentication、Authorization、Token、Cookie、CORS。它們分別在處理身分、權限、登入狀態和瀏覽器之間的安全邊界。

• API 設計與錯誤處理
  API 是 Frontend 和 Backend 溝通的規則。HTTP Request / Response、API Contract、Status Code、Error Response，讓雙方知道要怎麼呼叫、怎麼回應，出錯時又該怎麼說。

• State Machine
  當功能開始出現多個 State，而且不同 State 能做的事情不同時，State Machine 可以把 State、Event、Guard、Transition 整理成一套清楚的流程規則。

• 並發控制
  多個 Request 幾乎同時操作同一份資料時，就可能出現 Race Condition。Transaction、Optimistic Locking、Pessimistic Locking，就是在幫我們守住這種情況下的資料正確性。

走到這裡之後，一個功能看起來就不再只是一塊 Code。

當事情開始變複雜，我們也可以一層一層往裡拆：

規格有沒有說清楚？
↓
正確行為怎麼驗證？
↓
Frontend / Backend 的 Contract 有沒有對齊？
↓
目前的 State 允不允許這個操作？
↓
如果兩個 Request 同時來，結果還會不會正確？

不是每個功能都一定會遇到全部的問題。

但至少當一個功能開始變複雜時，我們已經多了幾個方向，可以知道現在該先往哪一層看。

第三關｜實際運行＆優化：功能做完了，接下來還要看它跑得好不好

走到第三關，我們終於把視線從「功能怎麼做」拉到「系統怎麼跑」。

因為 Code 在本機正常，不代表換到其他 Environment 也一定一樣；網站上線了，也不代表後面就沒有事情要處理。

版本怎麼交付、部署怎麼穩定、資料越來越多之後 Query 還快不快，都是系統真的開始運作之後才會越來越明顯的問題。

所以這一關，我們看了：

第三關｜實際運行＆優化
│
├─ 部署與 CI/CD
├─ Index Design
└─ Query 效能分析

• 部署與 CI/CD
  Deployment 讓應用程式可以在不同 Environment 裡正確運作；CI/CD 則把 Test、Build、檢查和部署流程自動化。

• Index Design
  Index 幫助 Query 更有效率地找資料，而設計時真正要看的，是系統實際的 Query Pattern。

• Query 效能分析
  EXPLAIN ANALYZE 讓我們看到 Database 實際怎麼執行 Query，也能確認 Index 有沒有真的被用上。

這一關處理的，其實都是同一件事：

功能真的進到實際環境之後，它還能不能穩定、有效率地繼續跑下去。

從 Deployment、CI/CD，到 Index Design 和 EXPLAIN ANALYZE，就是把「做得出來」再往後推到「真的跑得好」。

30 天後，再回來看 Vibe Coding

Day1 的時候，我一直在想：

AI 已經可以這麼快把 Code 寫出來了，那真正做一個完整專案，到底還差在哪裡？

走完這 30 天之後，我覺得差別其實不在「Code 是不是 AI 寫的」。

而是在我們知不知道，哪些事情不能只交給 AI 自己決定。

AI 很會根據常見做法，給出一個「看起來很合理」的答案。

但它很容易偏向常見、普遍適用的做法，不一定是最適合眼前這個專案的選擇。

真正開發時，我們還是要自己知道需求、限制和 Trade-off，才能判斷這個方案到底適不適合。

更麻煩的是，有些問題如果我們自己沒有意識到，AI 根本不一定會主動提醒。

像權限怎麼切、金鑰和 Secret 該放哪裡、哪些 Edge Case 要處理、多人同時操作資料時會不會出錯，甚至正式 Environment 裡還有哪些風險。

如果我們不知道要檢查這些事情，它們很可能連 Prompt 都不會出現。

我們也就不能期待 AI 一定會主動想到，再替我們把它們補好。

這也是我覺得 Vibe Coding 最容易漏掉的地方：

功能看起來跑起來了，不代表那些沒被提出來的問題就不存在。

所以在這樣的 AI 時代，我覺得我們真正該具備的能力，不是跟 AI 比誰寫 Code 比較快。

而是知道 需求要怎麼定義、方案要怎麼判斷、哪些風險不能漏掉，以及最後要怎麼驗證 AI 做出來的東西。

AI 可以幫我們把實作速度拉得很快。

但方向、選擇和最後的把關，還是要留在開發者手上。

希望這張地圖，可以陪第一次出發的人走得更有方向

雖然這 30 天分享的，不是什麼非常艱深的工程知識。

但我希望的是，能帶給第一次做專案的小白們一點點方向感。

希望當你真的站進一個完整專案裡時，不會只覺得眼前全都是陌生的東西，而是能慢慢看懂：

原來這些知識，都是有位置、也有彼此關聯的。

從 0 開始學程式的時候，最讓我慌張的常常不是「完全不會」。

而是明明已經學過一些東西了，真的遇到問題時，卻還是不知道現在卡在哪裡、也不知道接下來該往哪裡找。

後來做完整個專案，我才慢慢發現：

很多知識，也不用逼自己第一次遇到就全部學得很深。

有時候，先知道它為什麼存在、什麼時候可能會遇到，就已經能讓我們少繞很多路。

所以我很希望這 30 天，可以先替第一次做專案的人留下一點線索。

等你真的走到那裡時，也許會突然想起：

「啊，原來這就是當時看過的那一塊。」

那一刻，原本很陌生的問題，好像就不會那麼可怕了。

第一篇的時候，我把這個系列叫做一份「工程世界的食譜」。

現在走到最後，我更希望它是一張可以先放在手上的地圖。

不用告訴你每一步該怎麼走。

只要在不知道往哪裡去的時候，還能找到一點方向就好。

也謝謝一路陪我一起走完這 30 天的大家。

希望你們看完之後，都能從裡面帶走一些對自己有用的東西。

可能是一個以前沒想過的觀念，也可能只是在下一次遇到問題時，多知道一個可以往哪裡找的方向。

希望第一次出發的你，能比當時的我少一點迷茫。

30 天～通關啦！